Maybe we should consider extracting this from begin() into its own function e.g. ready(). That way the bridge could be started using begin() and the time during which Linux boots could be used to prepare other peripherals etc. instead of wasting it and then when that is done, the sketch can wait for Linux using ready(). @facchinm

@sebromero I understand your point, but I have mixed feelings about it.
That way we can't always make sure Bridge is used before the other side is ready (eg somebody could try and use Monitor to println during peripherals setup).
Besides we complicate the UX adding yet another call before exiting setup.

@eigen-value What if we do the following: begin() can stay blocking as it currently is waiting for Linux to boot, but we extract that check into its own non-blocking function e.g. ready(). The user has the option of preparing as much peripherals, buffering sensor data etc. as they can while Linux is being booted and just check periodically if Linux is ready and then start the bridge using begin(). That way the boot up time optionally be used for something useful without compromising the UX. As soon as begin() is called the user HAS to (busy)-wait for the boot-up to finish. In other words, advanced users have the option of calling the begin() function only when they know for sure the system has booted.